ASP.NET Security : The Membership and Role Management API (part 3) - Role

Managing Roles

Roles in ASP.NET simplify the implementation of applications that require authorization. A role is just a logical attribute assigned to a user. An ASP.NET role is a plain string that refers to the logical role the user plays in the context of the application. In terms of configuration, each user can be assigned one or more roles. This information is attached to the identity object, and the application code can check it before the execution of critical operations.

For example, an application might define two roles—Admin and Guest, each representative of a set of application-specific permissions. Users belonging to the Admin role can perform tasks that other users are prohibited from performing.

In ASP.NET, the role manager feature simply maintains the relationship between users and roles. ASP.NET 1.1 has no built-in support for managing roles. You can attach some role information to an identity, but this involves writing some custom code. Checking roles is easier, but ASP.NET 2.0 makes the whole thing significantly simpler.

The Role Management API

The role management API lets you define roles as well as specify programmatically which users are in which roles. The easiest way to configure role management, define roles, add users to roles, and create access rules is to use WSAT. (See Figure 17-11.) You enable role management by adding the following script to your application’s web.config file:

<roleManager enabled="true" />

You can use roles to establish access rules for pages and folders. The following <authorization> block states that only Admin members can access all the pages controlled by the web.config file:

<configuration>
<system.web>
    <authorization>
       <allow roles="Admin" />
       <deny users="*" />
    </authorization>
</system.web>
<configuration>

The order in which you place <allow> and <deny>tags is important. Permissions and denies are processed in the order in which they appear in the configuration file.

WSAT provides a visual interface for creating associations between users and roles. If necessary, you can instead perform this task programmatically by calling various role manager methods. The following code snippet demonstrates how to create the Admin and Guest roles and populate them with usernames:

Roles.CreateRole("Admin");
Roles.AddUsersToRole("DinoE", "Admin");
Roles.CreateRole("Guest");
string[] guests = new string[2];
guests[0] = "JoeUsers";
guests[1] = "Godzilla";
Roles.AddUsersToRole(guests, "Guest")

At run time, information about the logged-in user is available through the HTTP context User object. The following code demonstrates how to determine whether the current user is in a certain role and subsequently enable specific functions:

if (User.IsInRole("Admin"))
{
      // Enable functions specific to the role
      ...
}

When role management is enabled, ASP.NET 2.0 looks up the roles for the current user and binds that information to the User object. This same feature had to be manually coded in ASP.NET 1.x.

The Roles Class

When role management is enabled, ASP.NET creates an instance of the Roles class and adds it to the current request context—the HttpContext object.

Table 5 lists the properties available in the Roles class. All the properties are static and read-only. They owe their value to the settings in the <roleManager> configuration section.

Some methods in the Roles class need to query continuously for the roles associated with a given user, so when possible, the roles for a given user are stored in an encrypted cookie. On each request, ASP.NET checks to see whether the cookie is present; if so, it decrypts the role ticket and attaches any role information to the User object. By default, the cookie is a session cookie and expires as soon as the user closes the browser.

Note that the cookie is valid only if the request is for the current user. When you request role information for other users, the information is read from the data store using the configured role provider.

The Role Provider

For its I/O activity, the role manager uses the provider model and a provider component. The role provider is a class that inherits the RoleProvider class. The schema of a role provider is not much different from that of a membership provider. Table 6 details the members of the RoleProvider class.

You can see the similarity between some of these methods and the programming interface of the Roles class. As we’ve seen for membership, this is not just coincidental.

ASP.NET ships with a few built-in role providers—SqlRoleProvider (default), WindowsTokenRoleProvider, and AuthorizationStoreRoleProvider. The SqlStoreProvider class stores role information in the same MDF file in SQL Server 2005 Express as the default membership provider. For WindowsTokenRoleProvider, role information is obtained based on the settings defined for the Windows domain (or Active Directory) the user is authenticating against. This provider does not allow for adding or removing roles. The AuthorizationStoreRoleProvider class manages storage of role information for an authorization manager (AzMan) policy store. Supported on Windows Server 2003, Windows XP Professional, and Windows 2000 Server, AzMan is a separate Windows download that enables you to group individual operations together to form tasks. You can then authorize roles to perform specific tasks, individual operations, or both. AzMan provides an MMC snap-in to manage roles, tasks, operations, and users. Role information is stored in a proper policy store, which can be an XML file, an Active Directory, or an ADAM server.

Custom role providers can be created deriving from RoleProvider and registered using the child <providers> section in the <roleManager> section. Note that the process for doing so is nearly identical to the process you saw for the custom membership provider we explored previously.